I remember we explicitly removed ctrl+c handler at some point. @tdejager do you remember why?

We explicitly removed the CTRL+C handler in the pixi shell and the trampoline binaries because we want the underlying processes to handle CTRL+C. I am assuming that still works?

Also you can use ctrl_c from tokio so we don't need additional deps, check exec.rs.

I notice one weird thing with this change. It seems to work like I would expect when killing things run after this command. But canceling an install acts differently from cancelling a normal install:

This is repeatable for some reason, @wolfv or @baszalmstra would you know why that could happen? e.g. did I just introduce a terrible bug that my testing isn't verifying?

This is what the docs say. I wonder if we're in this situation - and need to come up with our own way of killing the remaining threads.

This PR is ready for review.

I tried to react on ctrl-c via tokio as suggested by @wolfv, but I couldn't get it to work. In order to reset the cursor, one has to write to stdout, and as far as I can tell no print goes through in that context.

When using the ctrl_c crate, everything works as expected.

I retested it and it did indeed fix the issues I had. So I'll merge it.

I tried to react on ctrl-c via tokio as suggested by @wolfv, but I couldn't get it to work. In order to reset the cursor, one has to write to stdout, and as far as I can tell no print goes through in that context.

Interesting. Even with flush?

But - whatever works! :)

Interesting. Even with flush?

I didn't try flushing, but since stdout is line-buffered, it should still have worked with println!

Not sure if that is still true when the terminal is e.g. set into raw mode for the selector thing.

Not sure if that is still true when the terminal is e.g. set into raw mode for the selector thing.

Mmmh interesting, will try flushing tomorrow

Flushing doesn't help, unfortunately, let's stick with the ctrlc crate for now